NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/220

Text File | 1996-08-06 | 7.2 KB | 150 lines

Newsgroups: comp.lang.c,comp.std.c
Path: blackbush.xlink.net!slsv6bt!slsv6bt!kanze
From: [e-mail] (James Kanze US/ESC 60/3/141 #40763)
Subject: Re: Integral conversion e.t.c. (was: Re: Hungarian notation)
In-Reply-To: [e-mail]'s message of 29 Jan 1996 16:05:18 GMT
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: SEL
References: <[e-mail]> <[e-mail]>
    <[e-mail]> <[e-mail]>
    <4edqh2$[e-mail]>
    <[e-mail]>
    <[e-mail]>
Date: 29 Jan 1996 19:13:12 GMT

In article <[e-mail]> [e-mail]
(Tanmoy Bhattacharya) writes:

|> In article <[e-mail]>
|> [e-mail] (James Kanze US/ESC 60/3/141 #40763) writes:
|> <snip>
|>    I think the crux of Michael Furman's question lies therein.  Does the
|>    standard require a diagnostic if the function main is not of one of
|>    the two types given?

|> No diagnostic is _required_, but irrespective of whether a diagnostic
|> is produced, there is no guarantee how the program will behave. This
|> is a quintessential example of undefined behaviour. An implementation
|> is free to define whatever meaning it chooses for this, exactly as it
|> is free to change the meaning of the entire rest of the program based
|> on this one statement.

Again, I think that one should make the distinction (at least in
comp.lang.c) between undefined undefined by the standard, and really
undefined.  The distinction is not defined in the standard, but is
very present in real life.  Thus, dereferencing a NULL pointer is
undefined, and while an implementation is free to define it if it
likes, in practice, none will define it to do anything good.  Adding a
third parameter to main is also undefined according to the C standard,
but most Unix compilers (and maybe others) do define it in a very
useful way; as far as I know, Posix may even define it so.

Although I find it hard to explain precisely the difference, I would
generally consider counting on implementation defined behavior in
derefencing the null pointer bad practice.  On the other hand, using
the added parameter to main wouldn't particularly bother me,
especially if, as is the case in most of my applications, the program
is intimely bound to Unix anyway.

This is always a delicate line.  A Windows program using far and near
pointers: I don't believe they can avoid it, and the program surely
won't run on anyother platform without major modifications.  A filter
program invoked from the DOS command line: I'd consider the use of far
and near a major flaw, and would heartily condemn a design which
required it.

|>    To tell the truth, I'm not sure what the answer is.  The text
|>    concerning main is in the chapter describing the environment.  It
|>    doesn't appear as a semantic restriction or anything.  It simply
|>    states that on start-up, a function called main will be called, and
|>    that the implementation must support the following forms.  It doesn't
|>    seem (to me, at least) to say anything about what other forms it might
|>    support, or what the implementation must do if given a fully other
|>    definition of main.

|> And hence, it is an undefined behaviour.

|>    Normally, I would expect (at the very least) a compiler to generate a
|>    warning or an error for a main that it did not support.  In fact,
|>    however, my compiler (gcc) accepts the following definition without
|>    the slightest complaint, although I'd rather not think about what will
|>    happen when I access parameter d:

|>        int main( char a , int b , long c , double d )

|> Undefined behaviour does not need diagnostic.

Agreed.  The above comment was addressed more to comp.lang.c, and
expresses what I would expect of a good compiler.  (Quality of
implementation issue.)  If the compiler knows what your are doing will
get you into trouble, and that there is no possible use for it, it
should warn you.

|>    |> For purposes of the C newsgroups, discussion of what is/isn't legal
|>    |> is generally restricted to strictly conforming C.

|>    Yes and no.  In comp.std.c, the discussion is exactly about what is
|>    legal according to the standard.  In comp.lang.c (to which this
|>    article is also cross-posted), the discussion should generally be a
|>    bit more open.

|>    Thus, for example, in comp.std.c, a program with a variable named far
|>    is illegal, and that is it.  In comp.lang.c (and I hope in its

|> Huh? A variable named far is perfectly legal.

Typo.  I meant legal.

|>    moderated variant), I would hope that someone would point out that,
|>    legal or not, it's going to get you into trouble.

|> I hope that situation changes soon in the future. Implementation
|> extensions must not encroach upon user name space: the C standard
|> attempts to formalize the distinction between user and implementation
|> name spaces: compilers ought to follow it. Not only in law, but also
|> in spirit.

I agree, but...

Try naming a global function read, and see what happens (on most
compilers, anyway).  In fact, the Posix standard requires it, and
thus, you cannot be Posix compliant without encroaching upon the user
name space.  (For example.  I'm sure that most other systems will have
similar constraints.)

|> For example, assuming that the concept of a far pointer is truly
|> required (It is really an exceptional circumstance which truly
|> _requires_ it; a compiler should usually figure out whether a near or
|> far pointer will work better: but that is a separate discussion), a
|> compiler should invent a keyword in the implementation name space
|> (e.g. __far) for it. It may provide a non-default switch
|> /backward-compatible to allow it to recognize far as a keyword and
|> treat it as a syntax error if used as a variable name.

|> But I agree that discussions in comp.lang.c should also take care of
|> current realities, even if those realities are fossils of an era long
|> past, frozen in time only by the arrogant ignorance of a large body of
|> users with a narrow view to the future.

Well, I'm not sure that I'd consider Posix a fossil of an era long
past, although it certainly reflects a long history.

I'm not sure where to draw the line.  Discussions of `read' certainly
don't belong in c.l.c.  But simply telling someone that his system is
broken because printf stopped working when he declared a global read
is not going to help anyone, even if, strictly speaking, it is true
according to the standard.

I may be oversensitivized to this problem.  My usual hang-outs are the
C++ groups.  Given the speed the C++ standard has evolved, there is no
such thing as a conforming compiler, and most people have to get their
programs working now, and not in 10 years time.  As a result, we do
spend a lot of time talking about compiler idiocyncracies.
--
James Kanze         Tel.: [phone]        email: [e-mail]
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
                -- A la recherche d'une activitΘ dans une region francophone